Method and apparatus for solving data packet traffic congestion

ABSTRACT

The present invention relates to data packet traffic congestion solving mechanism in a node of a Radio Access Network (RAN), said mechanism is capable of blocking the transmission of data packets between a user terminal (UT) and said node in both uplink and downlink directions, if a created blocking table indicates for a scheduler that said user terminal has been determined to have been idle for more than a pre-determined time.

TECHNICAL FIELD

The present invention relates to traffic congestion problems in RadioAccess Networks. More specifically, the present invention relates to amethod and a node for solving data packet congestion problems in a RadioAccess Network.

BACKGROUND OF THE INVENTION

As 3^(rd) generation (3G) mobile systems continue to evolve, there is agrowing market interest to support high bit-rate multi-media services.At the same time, 3G operators face a strong competition fromnon-conventional business models employing, for instance, IEEE 802.Xbased technologies that provide wireless access to Internet Protocol(IP) based multimedia services (IMS) or to the Internet.

Therefore, mobile operators are interested in augmenting their evolvingradio access networks (RAN) with a technology that provides them withthe ability to offer broadband IP based services, including TCP(Transmission Control Protocol) and UDP (User Datagram Protocol) basedapplications. In this document we will collectively refer to these highbit rate RAN:s beyond the existing 3G radio access technologies as “4GRAN”:s. Following documents are determined as close prior art:

-   [1] WINNER Project, “Description of identified new relay based radio    network deployment concepts and first assessment by comparison    against benchmarks of well known deployment concepts using enhanced    radio interface technologies”, IST-2003-507581 D3.1-   [2] C. Barakat, P. Thiran, G. Iannaccone, C. Diot, P. Owezarsid, “A    Flow based model for Internet backbone traffic”,    http://www.imconf.net/imw-2002/imw2002-papers/123.pdf-   [3] CISCO Document, Configuring QoS,    http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/12_(—)2_(—)25/conf/qos.pdf

A key observation is that 4G can advantageously be designed exclusivelyfor IP-based applications. That is, we can assume that the 4G RAN onlyinterfaces to the cellular operator's packet switched domain and allapplications running over 4G are IP based. It follows that it furthercan be assumed that all applications are rate adaptive, including TCPapplications and also many of the UDP applications, including VoIP(Voice-over-IP) applications employing rate adaptive coders.

A number of features have been listed for 4G RAN:

-   -   Exclusive Focus on IP-Based and Rate-Adaptive Applications    -   Only One Shared Traffic Channel per Cell    -   Instant Access to all of the Currently Available Bandwidth    -   No Support for Session-Based Admission Control & Resource        Reservation (Single Bearer Concept)    -   No Distinction Between Real-Time, Quasi-Real-Time, and        Non-Real-Time Applications    -   Lossless HARQ (Hybrid Automatic Repeat Request) with Bounded        Retransmission Delays per IP Packet    -   Congestion Control Based Purely on End-to-End Mechanism        (Flow-Class Queueing and Active Queue Management)    -   4G RAN Provides Per-Hop QoS (a la DiffServ) Through Different        Service Classes    -   Policy-Based Scheduling Between Service Classes

A key requirement on 4G systems is that the system complexity must bekept as low as possible. This applies particularly to Quality of Service(QoS) mechanisms that aim to provide some basic level of servicedifferentiation as well as to ensure system stability at congestionconditions.

The Internet does not provide any end-to-end QoS and, of differentreasons, is unlikely to ever do so. The per-hop model of DifferentiatedServices (DiffServ, DS) is an attractive mechanism to provide QoSbetween edge nodes of a network, and therefore it is well suited for thepurpose of providing QoS in a 4G RAN. DiffServ (according to thestandard documentation IETF RFC2475) has been partly successful in theInternet where it is mainly implemented within the domain of oneoperator. DiffServ uses the 6-bit DSfield in the IP header to mark theservice class of an IP packet. A big advantage with this approach isthat IPsec (IP security mechanism) does not encrypt the DS field. IPsecis increasingly used, e.g., for corporate access. Therefore, the 4G RANis envisaged to implement to provide different service classes. Theservice class of an IP packet is marked in the DS field. It is a 4Goperator's freedom to decide how many service classes to be supported.

Hence, the term Quality of Service (QoS) is defined as: “A network issaid to support QoS if it is able to offer different and differentiablelevels of service Quality over a shared infrastructure”.

With this definition of QoS, it should be noted that when the load onthe network is low and all user terminals (UT) have sufficient coverage(sufficiently high receiver level) then there is no difference betweenthe different service classes. In those situations the 4G RAN cantransport data faster (without IP packet losses and sufficiently lowdelays) then the applications currently used by all UTs in a cell candeliver the data.

An important feature that 4G needs to support is a mechanism by which anoperator can associate certain QoS levels with applications provided bythe operator through its service network or by 3^(rd) parties chosen bythe operator. The services may be divided into “public” and “private”service classes. Public service classes are offered publicly and can besubscribed to by 4G users. The idea is that each UT belongs to exactlyone public service class, e.g. one of “gold”, “silver” or “bronze”. Thepublic service class gold could be tied to the user's subscription.Private service classes are not available to 4G users, but can only beset by a 4G operator. The idea is that packets that belong to anapplication chosen by the operator are assigned to a private serviceclass, hereafter denoted as platinum. In that way a 4G operator canensure that those packets get differentiated treatment in the 4G RAN,e.g. priority over packets of public service classes. With this approachit will be possible to emulate guaranteed bit rates that can beassociated with a specific service chosen by the 4 G operator. Thisrequires an appropriate network dimensioning and a corresponding policyfor handling the different service classes (priorities, minimum bitrates, etc.).

Consider the QoS supporting system architecture of FIG. 2. As theoverall traffic load in the system increases, the system's congestionlevel starts increasing and eventually only platinum user traffic can beserved (due to the second level scheduling mechanism).

When the traffic load from platinum users alone reaches high loadregions, there is a need to prioritize some platinum users. That is,there is a need for an algorithm that determines which platinum users toschedule over the radio interface when the system is congested to theextent that not all platinum traffic can be scheduled.

This problem is non-trivial because the system does not differentiatetwo users (two UT:s) that belong to the same priority class (e.g.platinum). As in FIG. 2, the second level scheduler may be associatedwith an interclass policy and it may also keep track of the age ofoutstanding IP packets. These pieces of information are however notsufficient, since these do not allow to distinguish between users of thesame class (e.g. platinum) that have outstanding IP packets with thesame age.

Shortly put, there is a need for an algorithm that determines which UT'ssessions should not receive any scheduling resources at the MAC level inthe case of congestion. This problem is referred to as the intra-classUT blocking problem.

BRIEF DESCRIPTION OF THE INVENTION

The proposed solution to said problem allows to block UT:s fromaccessing the radio interface (Down-Link (DL) and Up-Link (UL)) withoutrelying on explicit session- and flow-based signalling. In the DL itdoes not require any signalling at all (not even on the medium accesscontrol (MAC) layer).

This invention can be seen as an important puzzle piece in devising alow complexity yet efficient QoS mechanism that is applicable for rateadaptive IP based applications over wireless links. The basic idea ofthe proposed QoS mechanism is to take advantage of the 4G specificassumptions (high bit rate, low congestion probability, adaptive IPbased applications) and provide service differentiation without sessionlevel signalling and admission control. Such QoS mechanism is arguablyless application specific, requires minimum amount of state informationand does not need pre-application QoS signalling and resourcereservation.

The present invention relates to a traffic solving method according toclaim 1. Different variations of the method are defined by the dependentclaims 2-12.

The present invention also relates to a node according to independentclaim 13. Said node comprises means for performing the invented method.Different embodiments of the node are defined in the dependent claims14-20.

The merit of the current invention is that it overcomes an importantproblem that is related to such QoS mechanism, namely the problem ofblocking some of the user terminals during high congestion situationswithout requiring session establishment and UT-RAN signalling proceduresto perform admission control and resource reservation prior to user datatransmission. As such, the proposed mechanism is required to ensuresystem stability when there is congestion in the network.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will in the following be described in more detail withreference to enclosed drawings, wherein:

FIG. 1 is a block diagram schematically illustrating a cell and somefunctional elements in a Radio Access Network (RAN) for cellular radiocommunication.

FIG. 2 is a block diagram showing schematically a configuration of aprior art scheduler architecture according to prior art.

FIG. 3 is a command signalling scheme in the scheduler architectureaccording to the prior art.

FIG. 4 is a block diagram showing schematically a configuration of ascheduler architecture according to the invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates a Radio Access Network (RAN) for cellular radiocommunication, such as UMTS (Universal Mobile TelecommunicationsSystem). The ability to use a user terminal UT (UT-1, UT-2, UT-3, . . .), e.g. mobile radio terminal, for radio communication purposes within acell C (C-1, C-2, . . . ) is provided by a node 2, e.g. Radio NetworkController, (base station controller in GSM (Global System for Mobilecommunication)), etc, that is connected to another node 4 of thenetwork, a base station antenna 4, that is strategically located in thecell for accomplishing best possible radio signal coverage (In UMTSterminology, a base station is usually denoted as a node B that iscontrolled by a RNC, however, in a more general sense the RNC may alsobe regarded as and denoted a node of a system or network). Each RNC nodeis usually controlling a number of cells and node Bs via a number ofsignal connections 8. In this schematic illustration, the base stationantenna 4 is located in the centre of the cell, although other locationsthan the centre is possible. A base station antenna 4 comprises at leastone antenna, omni directional or directional, connected to a radiotransceiver arrangement (not shown). A user terminal UT and the RNC nodeare able to communicate with each other via the base station antenna 4and the air interface in both directions, up-link (Ulink) from the userterminal UT to the base station antenna 4, and down-link (Dlink) fromsaid base station antenna 4. The mobile radio telephone communicationsystem comprises a Radio Access Network RAN that usually comprises anumber of RNC nodes that are mutually connected via a number ofconnections 6 and even connected to other networks, such as a corenetworks, PSTN, ISDN, LAN, WLAN etc. The transceiver arrangement (notshown) is monitored and controlled by the radio network controller. Thefact that the mobile radio communication system is described as a UMTSsystem should be regarded as a pedagogical simplification rather than alimitation of the scope of the invention. The invention is therefore notrestricted to one mobile radio communication standard, on the contrary,the invention described below is applicable in any of the known mobileradio communication standards.

FIG. 2 is a block diagram showing schematically a configuration of aprior art scheduler architecture design 100 according to the WINNERproject [REFERENCE-1]. FIG. 2 is an embodiment for how the differentelements for 4G QoS handling could be implemented in the downlink. Thisembodiment comprises two public service classes, gold (G) and silver(S), and one private service class, platinum P. The service classpriority order is from highest service level to the lowest servicelevel, platinum (P), gold G and silver (S). However, other classconfigurations are possible within the scope of this invention. Atraffic situation involving N subscribers in the cell is assumed; Kplatinum subscribers, L gold subscribers, and (N-(K+L)) silversubscribers. Note that independent of its public service class, a userterminal UT can also belong to the platinum class when a correspondingapplication, e.g., a VoIP service provided from the 4 G operator'sservice network, is currently used.

It is preferred that all applications are rate-adaptive. Sincerate-adaptive application has congestion control as a standard, explicitsupport for congestion control is not necessary to design into a 4GRadio Access Network (RAN). Instead, flow-based queuing and active queuemanagement are preferably implemented in a 4G RAN [REFERENCE-2].

Like in 2G and 3G, there is at least one IP (Internet Protocol) packetqueue 10A, 10B (12A, 12B, . . . ) per User Terminal (UT) 10 (12, . . .)(one in Down-Link (DL) in a node of the RAN and one Up-Link (UL) in theUT (not shown). This is a direct consequence of implementing a separatelink layer per UT (as opposed to a link layer shared by all terminalslike in the standard IEEE 802.11). Different application packet flows toor from the same UT are separated or isolated. Otherwise, a bulk datatransfer could easily create head-of-line blocking and consequently poorquality for a concurrent VoIP session on the same UT. To avoid this,flow-based queuing, i.e. different flows or different classes of flowsare queued separately, may be used. Flow class may be defined on theidentical tuple of source and destination IP address.

Logically, the known QoS architecture design comprises three levels ofschedulers located in the 4G network. The first scheduler 22 isassociated with a user terminal and schedules competing packets fromdifferent applications. The second scheduler 28 selects a particularUT's queue and handles over the corresponding IP packet for the thirdlevel scheduler 30. This third level scheduler 30 is a MAC schedulerthat selects one of the outstanding, waiting IP packets for MAC levelscheduling.

QoS provisioning for applications running on a 4G user terminal (UT) isprovided by three levels of schedulers. The functions of these levelswill now be described in more detail.

There may be several applications 10A, 10B (12A, 12B; etc) running on asingle 4G UT 10 (12, 14, 16, 18, 20), each with associated trafficpattern and QoS requirements. Conceptually, applications generate IPpackets in queues in buffers that are typically managed by an operatingsystem.

Associated with each UT, there is a scheduler 22 whose task is todetermine which out of the outstanding packets waiting in theapplication queues should be served first. In this embodiment, aWeighted Round-Robin scheduler (WRR) is used, but other scheduler may aswell be used giving a fair share of the aggregate bit rate per UT (perservice class) to the different flow classes while accounting fordifferences in packet sizes. Alternatively, the user might be givencontrol over such a scheduler. The latter solution would allow advancedusers to overwrite default priorities for certain applications, e.g. fortheir favourite VoIP-Client. On this level, a mechanism for maintainingthe IP queues is used. Active Queue Management (AQM) is a provenmechanism to efficiently maintain IP queues. It is supported by manystate-of-the-art routers [REFERENCE-3]. AQM can either be operated with“packet drop” as the implicit congestion signal or with the ExplicitCongestion Notification (ECN) (described in IETF RFC3168), where insteadof dropping a packet, it is marked with “congestion experienced”. Thatmark is then echoed by the receiving rate-adaptive application (e.g.TCP). The key features of AQM is to react (drop or mark packets) beforethe queue has become full in order to leave buffer space to absorbtransient packet bursts, and to queue as many packets as needed tomaximize end-to-end throughput, but as little as possible to minimizeend-to-end delays.

At the next level 24 the 4G access point (AP) maintains a queue per UT.That is, the one IP packet that has been selected by the first level ofscheduler 22 is placed into this per-UT queue. These logical queues 26at the AP are the ones that have a Hybrid Automatic Repeat Request(HARQ) sender 24 association with their peer entities located at theuser terminals (not shown) [REFERENCE-1]. The task of the second levelof scheduler 28 is to determine which IP packet(s) out of theoutstanding ones should be selected for MAC level scheduling 30. Thisscheduler may take into account inter-class policies (that is priorityhandling among the different service classes P, G and S) and also theage of the 1P packets that are waiting in the per-UT queues 26.

Scheduling between the different service classes P, G and S is whatdetermines the level of QoS provided to any specific service class.

Scheduling within one service class determines how UTs of the sameservice class are treated with respect to each other, e.g., fairnessbased on number of bytes or packets sent, fairness based on amount ofconsumed radio resources, etc.

One scheduler, the Policy-based Scheduler 28, should perform thescheduling between service classes.

As far as possible, the operation of that scheduler should be determinedby operator policies, i.e., as little functions, features, and policies,as possible should be hardwired into the scheduler by 4G standards orvendor-specific 4G implementations.

Below, a number of examples for scheduling policies are given that couldbe defined.

With a single private service class (platinum) a 4G operator candetermine how much bandwidth per cell should be reserved to servicesprovided from the 4 G operator's service network. This can (should) bemade adaptive to the number of users actually using the service at agiven point in time, the bit rate required by the service for fullquality, etc.

With two public service classes (gold G, silver S), the 4 G operator candecide that the gold G class gets absolute priority which during peaktraffic times may lead to the starvation of the silver traffic. Instead,a certain minimum bandwidth could be reserved for gold traffic; againadaptive based on the number of active (sending and/or receiving) UTs inthe gold class.

Different fixed scheduling weights (proportional fairness withpriorities) could be assigned to the different service classes.

Minimum bit rates could be assigned per service class potentiallydepending on the receiver signal strength of a particular UT. Forexample, a minimum of 2 Mb/s for platinum users at a receiver level of 3or better, a minimum of 0.1 Mb/s for gold users at a receiver level of 4or better, and no minimum for silver users.

In this design the Policy-Scheduler and the MAC-Scheduler 30 are kept asseparate entities. That way the MAC-Scheduler 30 can operateindependently focusing purely on multi-user gains through channeldependent scheduling.

The MAC-Scheduler is controlled from the Policy-Scheduler 28 throughSend-Tokens 32 that the Policy-Scheduler assigns on request from theMAC-Scheduler.

Each Send-Token 32 belongs to one particular UT-i and is “valid” for thesuccessful transmission of one L2-PDU (IP packet).

Apart from inter-class policies, the Policy-Scheduler 28 also needs totake the “age” of an IP packet into account. The idea is that each IPpacket gets assigned a timestamp, e.g., the current system time, onentering the IP queue. The “older” a packet gets the higher its priorityor weight becomme, and the higher its probability of getting scheduledby the Policy-Scheduler. We assume that a HARQ sender 24 always placesthe oldest L2-PDU (IP packet) retransmission in front of there-/transmission queue, i.e., retransmissions always have priority overnew transmissions.

The idea is that the MAC-Scheduler 30 always requests tokens 32 in a waythat it always has a sufficient amount of tokens to its disposal toallow for sufficiently high multi-user gains.

At the same time the MAC-Scheduler must ensure that it can transmit thepayload associated with all of the tokens 32 it holds within a smallamount of time, e.g., in less than 10 ms. Otherwise, the MAC 30 couldcreate head-of-line blocking and excessive delay. When the MAC-Schedulerschedules a token 32, it offers the corresponding UT a certain amount ofchunks of a given channel quality (CQI) 34. The UT then decides how manyof the chunks it wants to use and generates a matching forward errorcorrection (FEC) fragment 36.

Subsequently, the MAC-Scheduler schedules the next tokens until it has“filled” a transmission frame (Frame Bits or MAC Protocol Data Unit).Like the Policy-Scheduler 28 maintains the age of a packet, theMAC-Scheduler needs to maintain the age of a token. This is to avoidstarvation of the UT belonging to a particular token. Thus, the older atoken becomes, the more likely it becomes scheduled by the MAC-Scheduler30; even if at that time still only few chunks with good channel quality(CQI) exist.

Effectively, this means that the ultimate decision about if and when anIP packet is transmitted lies with the Policy BasedScheduler (PBS) 28,since the MAC scheduler sooner or later has to schedule the IP packetsassigned to it. This also means that service classes are transparent tothe MAC-Scheduler 30.

The function of the above described 4G scheduler architecture for QoShandling will now be described with reference to the signalling schemeof FIG. 3.

IP Data Packets belonging to a certain application and addressed to anUT arrive to the first scheduler level 22. The IP packets, waiting to beselected for transmission by a HARQ-sender 24, are placed in a queueaccording to a per flow class queuing in a buffer 26. In the next step,the HARQ-sender 24 generates a send request to the next level scheduler28, the PBS, which will set a IP packet time when the request wasreceived. The PBS receives only one request per UT.

The PBS 28 checks inter-class policy and the age of the IP packets. If arequest is accepted, the PBS issues a send-token to the CD-MAC (ChannelDependent Medium Access Controller). The UT is a candidate whose IPpackets are waiting in the HARQ buffer to be transmitted over the radiointerface to the corresponding peer HARQ in the UT. The issuedsend-token is stored in a memory space, candidate room, administratedand operated by the CD-MAC scheduler 30. The CD-MAC maintains peer-UTtimers, which involve that each UT has its own timer.

It is therefore possible for the CD-MAC scheduler to monitor the age ofeach send-token, and to drop a token if said send-token exceeds apre-determined age.

Said MAC scheduler 30 is token controlled and there is only onesend-token per UT waiting to be served. A send-token stores informationabout its UT candidate. As the CD-MAC knows which UTs are candidates,the MAC checks the radio channel quality, CQI, of each UT represented inthe candidate room. One UT that is contacted by the MAC responds bysetting Forward Error Correction (FEC redundancy in correspondence tothe channel quality (the better channel quality, the less the requiredFEC redundancy bits). The MAC scheduler 30 communicates directly withthe HARQ senders 24 (without informing the PBS) and sets the FEC leveldue to the measured and determined CQI. If the MAC 30 has been able tocommunicate with an UT, the MAC sends a “Fetch HARQ packet”-commandincluding the necessary FEC level to said HARQ sender. On the contrary,if the UT is determined to be unreachable, the MAC 30 sends a “Drop HARQpacket”-command to the HARQ sender in question.

If the HARQ sender in question receives a “Fetch HARQ packet”-command,the HARQ provides the IP packets with a HARQ header involving thecurrent FEC level for the channel. The HARQ sender transmits the HARQpackets to the corresponding peer HARQ in the UT. When said peer HARQsuccessfully receives the data packets, it returns an acknowledgementback to its peer HARQ in the RNC. When the HARQ has received theacknowledgement, the HARQ sends an “Acknowledgement received”-indicationto the MAC, which will drop the send-token in the candidate room.

In some situations, it will become necessary to select among usersbelonging to the same class. This problem is not addressed in the aboveknown architecture.

This intra-class scheduling problem arises when the schedulers and theradio communication interface are unable to serve all incoming IPpackets belonging to the same class. Accordingly, this involves that thedata packets will have to queue too long in the system. The queues willover-flow. This situation is called traffic congestion. It is thereforenecessary to select and give precedence to some UTs over other UTswithin the same class. This is called intra-class selection. Inter-classselection, i.e. selection between UTs from different service classes, isprovided for by the operator in the traffic policy integrated in thePolicy Based Scheduler 28.

In prior art systems, this problem is removed by the use of theAdmission Control. However, the Admission Control involves signallingover the radio interface. Signalling will limit the available radioresource and bandwidth. Therefore, admission control is not necessarilyprovided for in the proposed 4G system according to the Winner project[REFERENCE-1], and said system lets each user start up and starttransmitting data packets. An invented intra-class selection mechanismavoiding radio signalling or making use of a strictly limited radiosignalling is therefore of great interest.

A possible solution is random selection of UTs within a class. However,in the following a solution of the selection problem according to theinvention will be described, with reference to FIG. 4. Many details ofthe architecture have already been described above in connection withFIG. 2, and common details have therefore the same reference number.

The invention is a traffic congestion solving method comprising ablocking mechanism that involves that the Channel Dependent MACscheduler 30. The CD-MAC maintain peer-UT timers 38, which involve thateach UT 46 has its own timer. Further, a CD-MAC scheduler registersexisting UTs in the cell in a TABLE 40, even denoted as blocking table.

The invented mechanism will start at congestion or congestion warningand comprises the step of classifying different UTs as ACTIVE 42 or IDLE44, and the step of storing this information in a blocking table 40comprising as many TIMERS 38 as there are UT:s in the system. Theblocking table 40 is maintained by the Channel Dependent MAC Scheduler,when congestion or congestion warning is present. The blocking table 40is a registry over all UT:s that is currently in the system and itmaintains information about which UT:s are active or inactive. Theinformation in the cell about the existing UT:s in the cell is collectedfrom the send-tokens, which store UT information besides the age oftoken timer information.

During congestion or congestion warning, the MAC scheduler takes intoaccount both this piece of information and the CQI information whenselecting a HARQ packet for transmission over the radio interface. Oncethe UT:s are associated with an ACTIVE/INACTIVE state, this piece ofinformation can be used by the MAC scheduler. In order for thisACTIVE/INACTIVE state information to be maintained, there is a need fora mechanism that classifies UT:s as ACTIVE/INACTIVE and ensures thatthis state information is kept updated in the BLOCKING TABLE 40 as longas the congestion or pre-congestion situation exists.

Congestion Detection:

The MAC scheduler 30 and the PBS scheduler 28 will be able to detectcongestion and/or a congestion pre-state. The node is therefore providedwith congestion monitoring means, which is possible to implement incomputer software or hardware. When the system is very close tocongestion, user terminals belonging to lower service classes, e.g. goldor silver, may already be totally blocked from transmitting datapackets.

To be able to determine a congestion pre-state, or congestion warningstate, it is necessary to define a congestion level. The congestionlevel could be defined as the ratio between number of incoming sendrequests from the HARQs per time unit, i.e. incoming rate, and the totaldown link capacity per time unit, or the out-going rate of packets, willexceed a pre-determined threshold value. Another useful congestion leveldefinition is the sum of send-tokens in the candidate store in the MACscheduler will reach a critical number. Further one usable definition ofbeginning congestion or actual congestion is that the time-sum of allsend-token timers in the candidate store exceeds a pre-set time valuethreshold, e.g. 10 ms. When the congestion warning mechanism detects acongestion warning state or an actual congestion, the MAC scheduler isable to create said described blocking table.

Classification Algorithm:

At congestion or congestion warning state, each UT in the candidatestore is classified as IDLE in the blocking table 40.

When the MAC scheduler schedules a HARQ packet for transmission itawaits the successful transmission of the packet over the radiointerface. The MAC scheduler drops the send-token after the HARQ senderalgorithm has successfully completed transmission of the current HARQpacket. Once a HARQ packet has been successfully transmitted, the MACScheduler changes the corresponding UT:s entry in the blockdng table 40from IDLE to ACTIVE. It also sets the TIMER of this UT to a largepositive value N.

After each successfully scheduled HARQ packet, the MAC Schedulerdecrements N for each UT, except for the one UT whose packet has justbeen scheduled. When a UT:s TIMER reaches zero (i.e. N becomes zero),its status is again classified as IDLE. Alternatively, N is decrementedafter a predefined amount of time irrespective of the scheduled HARQpackets. It is also important to realise, that it is not possible toclassify an UT as idle or active by only looking at the age of one ofthe send-tokens belonging to an UT. It is necessary to consider allsend-tokens of an UT and if all send-tokens are too old to betransmitted, the UT is considered to be IDLE.

Blocking Mechanism:

At congestion, the MAC Scheduler 30 drops send-tokens and correspondingHARQ Packets whose UT is currently classified as IDLE. Thereby, ACTIVEUT:s have a higher probability that their HARQ packets get scheduled.The above algorithm provides a simple means to make an adaptivedifferentiation between ACTIVE and IDLE users during congestion periods.In broad terms, the system should be dimensioned such that suchcongestion periods should be rare. That is, during normal and even“lighter” congestion periods the service class based differentiationshould be sufficient to differentiate between users and to preservesystem stability. In the rare case, when the platinum users aloneoverload the system, there is however a need to make intra-classdifferentiation possible. It is during such severe congestion periods(exceptionally many call initiations within a cellular cell within ashort time interval, referred to as the ‘New Year's Eve” phenomenon)that the current invention becomes applicable. Typically, the systemload increases from a “normal” level to the extreme congestion levelgradually.

Consider the situation when there are no platinum users in the system.The gold and silver users however generate a traffic load that bringsthe system into a severely congested state. The problem now becomes todifferentiate between gold users, much the same way as it was describedfor platinum users. The described intra-class selection is applicablefor other service classes than the described “platinum users”.

The above described embodiment of the blocking algorithm was describedin the down-link (forward link) direction, from the RAN node of the cellto the UT.

However, the same functionalities and entities are present in the uplink(reverse link) as in the downlink case. In the user terminal, the IPpackets will be handled by a HARQ and organized in at least one queue,and the IP packets will be waiting to be sent to the peer-HARQ. Thescheduling control is handled by the base station (or radio network)controller, i.e. the BSC/RNC.

The uplink MAC scheduler does not have global knowledge over the stateof all of the UTs' queues. However, the only difference between thedownlink case and the uplink case is that the commands communicated inthe control plane between the HARQ senders and the uplink PBS and theuplink MAC scheduler will be transmitted over the air interface insteadof internal in the RNC node.

The present invention is also a node 2, e.g. Radio Network Controller,Base Station Controller, etc, in a Radio Access Network (RAN) forcellular radio communication. Said node 2 is signal connected to means,e.g. transceiver means, base station antenna 4, etc, for transmittingand receiving data packets (IP-packets) over the air interface betweensaid node 2 and a number of user radio terminals UT (UT-1, UT-2, . . . )within the cell area C-1. Said node 2 comprises a channel dependentscheduler 30 for monitoring and controlling UT scheduling due to ChannelQuality Identification (CQI) and stored data packet information 32, e.g.tokens, belonging to data packets waiting to be selected fortransmission to or from identified and addressed user terminals UT. Saidnode 2 comprises a number of means that provide the capability toperform the invented method for solving traffic congestion, which in thefollowing will be presented.

The node 2 comprise means for creating a table 40, hereafter denoted asblocking table, comprising those of said user terminals that belongs tothe same service class (P, G, S, . . . ), when a state of trafficcongestion has occurred or is close to occur. Further, the node 2comprises means for maintaining said blocking table 40 as long as saidcongestion state is present, preferably only as long as said congestionstate is present. Furthermore, the node 2 comprises means for blockingthe transmission of data packets between a user terminal UT and saidnode 2 in both uplink (Ulink) and downlink (Dlink) directions when theblocking table 40 indicates for said scheduler (30) that said userterminal (UT) has been determined to have been idle for more than apre-determined time. The node 2 is further provided with means forallowing transmission of data packets between the user terminal and saidnode in both uplink and downlink directions when the blocking tableindicates for said scheduler that said user terminal is determined to bestill active. All the above mentioned means are preferably implementedas program instructions readable and processable by a controller, suchas a computer, processor, central processing unit, micro-processor, etc,within or in connection to the node 2, e.g. in the radio networkcontroller (RNC). The program instructions may be implemented insoftware or hardware.

According to one embodiment of the invention, the node 2 has also meansfor introducing in said blocking table 40 one entry for each userterminal UT, and for each user terminal one per-UT timer and means forsetting each represented user terminal as IDLE and the correspondingper-UT timer to a pre-determined start value in said table.

Following listed means, defining different embodiments of the invention,are preferably implemented as program instructions readable andprocessable by a controller, such as a computer, processor, centralprocessing unit, micro-processor, etc, within or in connection to thenode 2, e.g. in the radio network controller (RNC). The programinstructions may be implemented in software or hardware.

-   -   means for changing a user terminal entry 46 in the blocking        table 40 from IDLE 42 to ACTIVE 44 if the corresponding data        packet(s) has/have been successfully transmitted, e.g. that an        acknowledgement has been received from the receiving party;    -   means for setting the counting value of the corresponding per-UT        timer 38 to a pre-determined start value;    -   means for setting the counting value of the corresponding per-UT        timer 38 to a pre-determined large positive start value N;    -   means for decrementing said counting value for each per-UT timer        38 for each successful transmission of data packets, except for        the one UT whose data packet(s) just has/have been successfully        transmitted;    -   means for decrementing said counting value for each per-UT timer        38 by a predetermined decrement value;    -   means for setting a user terminal as IDLE 42 when the        corresponding per-UT timer 40 reaches a pre-determined stop        value.

According to further one embodiment of the invention, the channeldependent scheduler 30 is a Medium Access Control (MAC) scheduler, whichis capable of blocking data packet(s) waiting to be selected fortransmission to or from an identified and addressed user terminal bydropping one or more corresponding send-tokens, representing stored datapacket information belonging to said user terminal when said userterminal is indicated IDLE in the said table due to the fact thatcorresponding per-UT timer has reached the pre-determined stop value.

In further one embodiment, the node also comprises a policy-basedIP/L2-PDU (Internet Protocol Layer 2 Packet Data Unit) scheduler 28 forscheduling accepted “send requests” generated by a sending entity 24 inthe node 2 to said MAC scheduler 30 that is able to store said acceptedsend requests as send-tokens 32. Said sending entity 24 may beimplemented as a Hybrid Automatic Repeated Request (HARQ).

It has now been described how the invented method and node comprisingmeans for solving data packet congestion are capable of detecting andhandling a congestion situation in a radio access network RAN withoutrequiring session establishment and UT-RAN signalling procedures toperform admission control and resource reservation prior to user datatransmission. The present invention is not limited to theabove-described preferred embodiments. Various alternatives,modifications and equivalents may be used. Therefore, the aboveembodiments should not be taken as limiting the scope of the invention,which is defined by the appending claims.

1. A data packet traffic congestion solving method for cellular radiocommunication comprising a Radio Access Network (RAN), said networkcomprising at least one node, said node comprising a scheduler formonitoring and controlling scheduling of data packet transmissions witha plurality of user terminals (UTs), wherein the method comprises thesteps of: creating a table identifying those of said UTs that belong tothe same service class (P) and identifying for each UT, a period of timethat the UT has been idle, when a state of traffic congestion hasoccurred or is close to occurring, the table being readable by thescheduler; maintaining said table as long as said congestion state ispresent; and providing priority to active UTs in the service class byblocking the transmission of data packets between a UT and said node inboth uplink and downlink directions, when the table indicates for saidscheduler that said UT has been determined to have been idle for morethan a pre-determined time; wherein the creating step, maintaining step,and blocking step are controlled by the scheduler, which is a MediumAccess Control (MAC) scheduler; and wherein the MAC scheduler is capableof blocking data packets waiting to be selected for transmission to orfrom an identified and addressed UT by dropping one or morecorresponding send-tokens, representing stored data packet informationbelonging to the identified and addressed UT, if the identified andaddressed UT is indicated IDLE in the table due to the fact that acorresponding per-UT timer has reached a predetermined stop value. 2.The method according to claim 1, wherein said method further comprisesthe step of: allowing transmission of data packets between the UT andsaid node in both uplink and downlink directions, when thescheduler-readable table indicates for said scheduler that said userterminal is determined to be still active.
 3. The method according toclaim 1, wherein said creating step includes the step of: recording insaid table, one entry for each UT, and for each UT, one per-UT timer. 4.The method according to claim 3, wherein said creating step includes thestep of: setting each represented user terminal as IDLE and thecorresponding per-UT timer to a pre-determined start value.
 5. Themethod according to claim 1, wherein said maintaining step includes thestep of: changing a UT entry in the table from IDLE to ACTIVE if thecorresponding data packets have been successfully transmitted.
 6. Themethod according to claim 5, wherein said maintaining step also includesthe step of: setting a counting value of the corresponding per-UT timerto a predetermined start value.
 7. The method according to claim 6,wherein said maintaining step also includes the steps of: setting thecounting value of the corresponding per-UT timer to a predeterminedpositive start value N.
 8. The method according to claim 7, wherein saidmaintaining step also includes the steps of: decrementing said countingvalue for each per-UT timer for each successful transmission of datapackets, except for the one UT whose data packets have been mostrecently successfully transmitted.
 9. The method according to claim 7,wherein said maintaining step also includes the step of: decrementingsaid counting value for each per-UT timer by a predetermined decrementvalue.
 10. A node in a Radio Access Network (RAN) for cellular radiocommunication, said node comprising a scheduler for monitoring andcontrolling scheduling of data packet transmissions with a plurality ofuser terminals (UTs), wherein the node includes a processor configuredto cause the scheduler to: create a table identifying those of said UTsthat belong to the same service class and identifying for each UT, aperiod of time that the UT has been idle, when a state of trafficcongestion has occurred or is close to occurring, the table beingreadable by the scheduler; maintain said table as long as saidcongestion state is present; and provide priority to active UTs in theservice class by blocking the transmission of data packets between a UTand said node in both uplink and downlink directions, when the tableindicates for said scheduler that said UT has been determined to havebeen idle for more than a pre-determined time; wherein the scheduler isa Medium Access Control (MAC) scheduler; and wherein the MAC scheduleris configured to block data packets waiting to be selected fortransmission to or from an identified and addressed UT by dropping oneor more corresponding send-tokens, representing stored data packetinformation belonging to the identified and addressed UT, if theidentified and addressed UT is indicated IDLE in the table due to thefact that a corresponding per-UT timer has reached a predetermined stopvalue.
 11. The node according to claim 10, wherein the processor is alsoconfigured to cause the scheduler to allow transmission of data packetsbetween a UT and said node in both uplink and downlink directions, whenthe scheduler-readable table indicates for said scheduler that said UTis determined to be still active.
 12. The node according to claim 10,wherein the processor is also configured to record in said table, oneentry for each UT, and for each UT, one per-UT timer.
 13. The nodeaccording to claim 12, wherein the processor is also configured to seteach represented UT as IDLE and the corresponding per-UT timer to apre-determined start value in said table.
 14. The node according toclaim 10, wherein said node also comprises a policy-based IP/L2-PDUscheduler configured to schedule accepted send requests generated by asending entity in the node to said MAC scheduler that is able to storesaid accepted send requests as send-tokens.
 15. The node according toclaim 10, wherein said sending entity is a Hybrid Automatic RepeatedRequest (HARQ) entity.